Radiocommunication circuits making it possible to embark client applications are known in prior art.
The radiocommunication circuit is for example an electronic radiocommunication module of the “WISMO” (registered trademark) family implementing the “Open AT” (registered trademark) concept of the WAVECOM company (applicant for this patent application), offering an environment for executing at least one onboard client application. It is clear that other environments for executing an onboard client application can be used, such as Java (registered trademark) or Python (registered trademark).
One of the problems of modules that provide abilities to embark the applications of their clients is that no guarantee on the available computing power is provided to the client in an optimized way.
Indeed, the function (software stack) for radiocommunication (GSM or CDMA cellular telephony for example) requires, according to its state, a very different computing power. The computing power of the platform (whereon the radiocommunication stack and the client application are executing) being finite at a given frequency, and the client application having a priority that is less than that of the stack, this client application will have only the remaining portion of computing power in order to execute. This can cause problems when the client application has calculations to perform and/or operations to carry out within a given period of time in order to not lose information (in particular when the latter is relayed in real time).
For example, when the client application is acquiring values in real time (for example every 10 milliseconds), it must process them (for example, calculate an average, a standard deviation, etc.) and store them in non-volatile memory in order to not lose them. To do this, it must carry out this processing with a given period of time (in our example, less than 10 milliseconds) otherwise after a certain period of time there will no longer be enough memory to store the raw values (before calculation), and some will be lost, which could be highly problematic and jeopardize the system as a whole.
The difficulty is that the GSM stack needs a computing power that varies according to the different states that it may have:                off (disconnected): the module is not connected to the GSM/GPRS network and as such cannot communicate;        searching for network: the module has lost the synchronization with the network (start-up/out of coverage, etc.) but is looking for a network whereon it can synchronize;        at rest (idle): the module is connected to the GSM/GPRS network. It is therefore able to receive, place calls, send/receive SMSs, initiate a GPRS connection but it is not making use of any of these possibilities;        a voice call;        a data call;        in data transfer (GPRS, EDGE, 3G, HSDPA, HSUPA, etc.);        in sending/receiving short messages (SMS);        in sending/receiving of supplementary service data (USSD).        
However, the onboard systems have in general at least one operating mode by battery and must therefore finely manage their consumption in terms of current. As such, overdimensioning the computing power of an onboard system comprising a GSM stack as a solution for overcoming the computing power peaks consumed by the GSM stack is not a viable solution for an autonomous onboard system since it results in a substantial overcost for the overall solution (the notion of optimal computing power is therefore primordial during the designing of an onboard system in order to not generate redhibitory overcosts).
The most important point is that it is impossible for the client application to know before the phase the needs in terms of power for the protocol stack.
For example, when searching for a network, there is no way for the client application to predict the moment when the system is going to find it and as such the load of the computing power required for the synchronization with the cellular network and consequently the computing power that will be lacking when this synchronization takes place, nor even the moment when this computing power will be lacking.
Likewise, the loss of synchronization network (for example when the GSM cells are too far away to be detected by the onboard system) results in a request for additional computing power from the protocol stack and could therefore impact the available computing power for the client application during the network resynchronization, with the dangers that this includes in terms of loss of data if this data is not processed rapidly enough.
As such, in an onboard system comprising a GSM/GPRS stack, most of the events processed by the stack and which impact the computing power left free to the client application cannot be predicted by the client application, and can as such impact the proper operation of the system as a whole.
In sum, the execution of a radiocommunication stack (for example a GSM/GPRS stack) requires considerable computing power that varies according to the states of this stack, with the risk of losing the synchronization with the network (and therefore to no longer be able to make/receive calls, send/receive SMSs, USSD, etc.).
According to a first known technique, not knowing what impact the execution of the client applications will have on the proper operation of their own radiocommunication stack (GSM/GPRS stack for example), and therefore on the proper global operation of their product, the manufacturers of radiocommunication modules (in particular intended for the M2M and automobile markets) do not provide their clients with the ability to guarantee a defined and optimized value of computing power regardless of the state of the radiocommunication stack.
Therefore at a computing power (also called CPU power) that is constant (i.e. at a clock frequency of the processor that is constant) the CPU power allocated to the client application depends on the activity of the radiocommunication stack. This can cause a problem when the client application requests more computing power than is allocated to it. At best, the client application will be slower. At worst, it will no longer operate. In both cases, when the situation occurs in the field, the consequences of this can be extremely damaging/substantial/costly.
For example, at 104 MHz, a standard platform provides 104 MIPS of CPU power. If we assume for example that the GSM stack/GPRS needs during a GPRS transfer (requested by the client application) 32 MIPS in order to execute, the client application can then take advantage of the remaining 72 MIPS. But if the application needs 85 MIPS to execute normally, it will be missing 13 MIPS. This situation can result in a malfunction or the stoppage of the operation of the client application.
According to a second known technique, the suppliers of radiocommunication stack (GSM stack/GPRS for example) provide a code which, compiled and executed on an associated platform, makes it possible to make/receive calls, etc. These suppliers of software solutions as such allows their clients to execute code at all levels, code which could therefore benefit from a defined and optimized computing power regardless of the state of the radiocommunication stack. But in no way do they guarantee as such that the radiocommunication stack will operate correctly. Furthermore, this involves much complexity in the designing of the client application and therefore a substantial expertise in the field of radiocommunications (GSM/GPRS for example).
For these reasons, this second alternative technique is difficult to be used, in particular by the clients in the M2M markets and all the more so by any person who is not an expert in the final application field of the global product as well as in the field of telecommunications, in particular GSM/GPRS technologies.
Therefore, most software architectures that allow external code to be embarked on a radiocommunication platform (wireless platform) are compliant with the first known technique (guarantee of the proper operation of the GSM/GPRS stack, but no guarantee as to the computing power supplied to the client application.